Fix right-edge redraw at terminal bottom#112
Conversation
|
Why did you close ? |
The display refactor (b735972) copied displayLine into displayLineRefactored for the main render path but dropped the pending-wrap handling the original had for input landing exactly on the terminal's right edge. Since the copy is the per-keystroke path, typing past the right edge on the bottom row erased the edge glyph and wedged the redraw (scrolling a row per key). The two functions otherwise drifted as identical copies — inline-suggestion work had to patch both, and this fix had to patch only one. Collapse them into a single displayLine used by both the main refresh path (renderInputArea) and the transient-prompt redraw (RefreshTransient), and give it correct right-edge handling: skip clear-to-end-of-line in the terminal's pending-wrap state (it can erase the edge glyph), then force the wrap before later clear/cursor-movement sequences. Includes the PTY regression test from PR #112 by @rztaylor, which fails without the fix (input wedges at the right edge) and passes with it. Co-authored-by: rztaylor <rztaylor@users.noreply.github.com>
|
For the record: this fix was valid and the bug it targets is real and still present on Investigating why turned up the root cause: the display refactor ( I've revived your fix in #117, folded together with a de-duplication of the two render functions, and kept your PTY regression test with a co-author credit. Thanks for the original diagnosis and test — sorry this sat closed. |
Summary
Fix a terminal redraw edge case when editable input lands exactly on the right edge of the terminal while the prompt is already at the bottom of the screen.
In that state, terminals can keep the cursor in a pending-wrap position. The renderer was still appending clear-to-end-of-line before forcing the wrap, which could erase the edge character and make subsequent keypresses scroll or redraw incorrectly.
Changes
Validation
GOCACHE=/private/tmp/reeflective-readline-pr.DPe91Q/.cache/go-build go test ./...